feat: add resolver-backed extension lifecycle API - #5

Summary

Adds a trusted Runtime embedding API for extensions whose source is provided by the Backend-owned, extension-scoped module resolver.

Implemented

• Add Manager:load_resolved(name, config, options), which resolves the entry module init, keeps nested require within the same owning extension namespace and records the source as resolver.
• Add Runtime:load_extension, Runtime:unload_extension and Runtime:list_extensions.
• Keep lifecycle APIs off the Frontend Protocol command surface. Remote editing clients do not acquire permission to load local code.
• Reject path-like extension names and nested module names before invoking the resolver.
• Cover entry + nested module loading, returned metadata, unload cleanup, resolver-disabled failure, missing entry and path traversal in Runtime integration tests.
• Document the API and its Backend-side security prerequisites.

Security / ownership boundary

Runtime validates namespace identifiers but does not access the filesystem. A real Backend resolver still must implement canonical path confinement, symlink/reparse-point protection, bounded reads, and Lua owner-thread delivery. This PR does not claim that the Backend resolver is implemented or that CDIN has live plugin activation end-to-end.

The lifecycle API is intentionally a trusted embedding surface. It is not exposed as request.command because there is not yet a product administrative authorization model for remote plugin management.

Verification

• Runtime CI on this PR.
• Review API semantics and compatibility.
• Backend integration remains tracked separately in Backend issue #14.

Related

• CDIN #111 — complete live editor integration and product release gates
• Runtime issue #4
• Backend resolver issue #14